Add ERC-7715 execution permission methods#311
Conversation
Add OpenRPC definitions for the ERC-7715 execution permission methods and their supporting schemas: - wallet_requestExecutionPermissions - wallet_getGrantedExecutionPermissions - wallet_getSupportedExecutionPermissions - wallet_revokeExecutionPermission These methods are already implemented in the wallet (via the permissions kernel Snap) and reachable over the EIP-1193 provider, but they are absent from the OpenRPC document. As a result they are not included in `KnownRpcMethods.eip155` (which `@metamask/chain-agnostic-permission` derives from this document), so they cannot be authorized in a CAIP-25 session and fail with an "unauthorized" error when invoked via the Multichain API (`wallet_invokeMethod`) — e.g. when used through MetaMask Connect. Adding them here makes them authorizable over the Multichain API, matching the existing EIP-1193 behaviour.
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
The schema defined both `address` and `from` with identical descriptions. ERC-7715 only specifies `from`, so drop `address` and clarify the `from` description to match the spec.
- Remove wallet_revokeExecutionPermission (not wired in extension/mobile; handler throws methodNotSupported with no processRevokeExecutionPermission hook) - Drop unsupported top-level request fields (signer, expiry); expiry is an expiry rule on the wire, not a top-level field - Require isAdjustmentAllowed on ExecutionPermission and to on ExecutionPermissionRequest (both required by 7715-permission-types) - Require context/dependencies/delegationManager on the response and factory/factoryData on dependency entries (needed to redeem permissions) - Demonstrate the expiry rule in the request/response examples
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 1e8b942. Configure here.
| chainIds: | ||
| - '0xaa36a7' | ||
| ruleTypes: | ||
| - expiry |
There was a problem hiding this comment.
Missing wallet_revokeExecutionPermission method from OpenRPC spec
High Severity
The PR description explicitly lists four ERC-7715 methods to add, but wallet_revokeExecutionPermission is missing from both openrpc.yaml and CHANGELOG.md. Only three methods were actually added. Since the whole purpose of this PR is to make these methods authorizable via the Multichain API's wallet_invokeMethod, omitting the revoke method means dapps using MetaMask Connect will still get UnauthorizedProviderError when trying to revoke execution permissions.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 1e8b942. Configure here.
There was a problem hiding this comment.
intentional — wallet_revokeExecutionPermission isn't wired in the wallet. createMetamaskMiddleware only passes the request/getGranted/getSupported hooks, and neither extension nor mobile provides processRevokeExecutionPermission, so the handler throws methodNotSupported. documenting it would make it authorizable over multichain while calls still fail. updated the PR description to drop it; will add when the client wiring lands.
Add `rules` to ExecutionPermissionRequest.required (the permissions-kernel Snap requires it; pass `[]` for no constraints) and bump the example expiry timestamps to a future date so copied examples don't request an already-expired permission.
jeffsmale90
left a comment
jeffsmale90
left a comment
There was a problem hiding this comment.
A couple of minor comments on here - the only one that I think is a genuine concern is the missing startTime in the example
| type: native-token-periodic | ||
| isAdjustmentAllowed: true | ||
| data: | ||
| periodAmount: '0x38d7ea4c68000' |
There was a problem hiding this comment.
There's also a required startTime parameter on native-token-periodic's data - this indicates the start of the first "period", and should be reflected in the example result also.
There was a problem hiding this comment.
added startTime to the periodic example (req + result) in d131dc5. kept the data schema generic since we don't enumerate per-type data fields. fwiw 7715-permission-types still types startTime as optional — might be worth aligning that separately if the snap requires it.
| type: boolean | ||
| data: | ||
| description: >- | ||
| Permission-type-specific data. All amounts are `0x`-prefixed |
There was a problem hiding this comment.
This is true of token amounts - timestamps and durations (amount of seconds 🤷) are represented as number type.
There was a problem hiding this comment.
good catch — reworded in d131dc5: token amounts are hex, timestamps/durations are numbers (seconds).
| - type: object | ||
| required: | ||
| - context | ||
| - dependencies |
There was a problem hiding this comment.
I don't think it's important to note here, but for interests' sake, dependencies is always an empty array, as it's a relic in the standard of a time when 4337 style smart contract accounts were the defacto delegator (now they are EOA's powered via EIP-7702).
There was a problem hiding this comment.
thanks, good to know. leaving it as-is for now — an empty array still satisfies the required marker, and the per-item factory/factoryData requirement just never triggers. can drop the requirement later if it's reliably always empty.
- Add `startTime` to the native-token-periodic example (request + result); it marks the start of the first period - Fix the ExecutionPermission `data` description: token amounts are hex, but timestamps/durations are numbers (seconds)
3 participants
Summary
Adds OpenRPC definitions for three ERC-7715 execution permission methods and their supporting schemas:
wallet_requestExecutionPermissionswallet_getGrantedExecutionPermissionswallet_getSupportedExecutionPermissionsNew
components/schemas:ExecutionPermission,ExecutionPermissionRule,ExecutionPermissionRequest,ExecutionPermissionResponse.Note
wallet_revokeExecutionPermissionis intentionally not included. While@metamask/eth-json-rpc-middlewaredefines a handler for it, the wallet does not currently wire it up —createMetamaskMiddlewarepasses only the request/getGranted/getSupported hooks (noprocessRevokeExecutionPermission), and neithermetamask-extensionnormetamask-mobileprovides that hook. Documenting it here would make it authorizable over the Multichain API while actual calls throwmethodNotSupported("no middleware configured"). It will be added once the client wiring lands.Motivation
These methods are already implemented in the wallet (handled by the permissions kernel Snap) and work over the EIP-1193 provider (
window.ethereum). However, they are absent from the OpenRPC document, which is the source of truth forKnownRpcMethods.eip155in@metamask/chain-agnostic-permission:Because the methods are not in this list, the Multichain API's
wallet_invokeMethodhandler rejects them:So any dapp invoking ERC-7715 over the Multichain API (e.g. via MetaMask Connect, which routes all EVM requests through
wallet_invokeMethod) fails withUnauthorizedProviderError: The requested account and/or method has not been authorized by the user, even though the same call succeeds over EIP-1193.Adding these methods to the OpenRPC document makes them authorizable within an
eip155CAIP-25 session scope. No additional wiring is required on the wallet side: once authorized, the request already flows through the sharedmetamaskMiddlewareto the execution-permission handler.Schema notes
The request/response schemas mirror the wire contract in
@metamask/7715-permission-typesand the transform applied by@metamask/smart-accounts-kit:ExecutionPermissionRequestwire fields arechainId,from(optional),to,permission, andrules. There is no top-levelexpiry/signer/address; time bounds are expressed as anexpiryrule ({ type: 'expiry', data: { timestamp } }), which is how the kit serializes a developer-suppliedexpiry.isAdjustmentAllowed(onExecutionPermission) andto(onExecutionPermissionRequest) are required.ExecutionPermissionResponserequirescontext,dependencies, anddelegationManager(needed to redeem the permission); each dependency entry requires bothfactoryandfactoryData.Changes
openrpc.yaml: 3 methods + 4 schemas (taggedMetaMask/Experimental/Multichain).CHANGELOG.md:[Unreleased]entry.Test plan
yarn buildregeneratesdist/build/openrpc.jsonwithout errors.openrpc.json.yarn testpasses (parseOpenRPCDocumentvalidates the document and dereferences all$refs, including the new schemas/tags/errors).KnownRpcMethods.eip155set after the filters applied by@metamask/chain-agnostic-permission.Downstream
After release, bump
@metamask/api-specsin@metamask/chain-agnostic-permission(MetaMask/core), then bump@metamask/chain-agnostic-permissioninmetamask-extensionandmetamask-mobile.Note
Medium Risk
Spec-only change, but it expands which delegate/execution permission RPCs are considered known and authorizable—downstream permission packages must pick up the release for Multichain routing to work.
Overview
Documents ERC-7715 execution permissions in the OpenRPC spec so dapps can use them through the Multichain API (e.g. MetaMask Connect), not only via EIP-1193.
openrpc.yamladds three methods (wallet_requestExecutionPermissions,wallet_getGrantedExecutionPermissions,wallet_getSupportedExecutionPermissions) with MetaMask / Experimental / Multichain tags, plus four schemas (ExecutionPermission,ExecutionPermissionRule,ExecutionPermissionRequest,ExecutionPermissionResponse) aligned with the existing wire contract (rules-based expiry, redemption fields likecontextanddelegationManager).CHANGELOG.mdrecords the addition under[Unreleased].wallet_revokeExecutionPermissionis intentionally omitted until clients wire it up.Reviewed by Cursor Bugbot for commit d131dc5. Bugbot is set up for automated code reviews on this repo. Configure here.